In traditional circuit-switched networks, such as the Public Switched Telephony Network (“PSTN”), each user endpoint is connected to at most one switching system. In a business enterprise, a business telephone is connected to a single Private Branch Exchange (“PBX”). A PBX is an intelligent switching point within a circuit-switched network that is responsible for routing calls to a plurality of internal nodes or public destinations via a single PSTN switching system.
Newer telephony networks that employ packet-switching technologies are growing in popularity. In particular, packet-switched telephony networks that use the Internet Protocol (IP) as a network protocol for transmitting and receiving voice data are becoming more prevalent. These so-called Internet Telephony (IT) networks have the potential to offer new features and services that are currently unavailable to subscribers of circuit-switched telephony networks. Conceptually, IT Networks differ from the PSTN systems in that they generally transmit voice data exchanged between two subscriber endpoints, according to an IP format. More specifically, they encapsulate voice data into data packets, which are transmitted according to an IP format in the same manner as textual data is transmitted from one computer to another via the internet.
The Session Initiation Protocol (SIP) is one of several protocols that may be used with the Internet Protocol to support Internet Telephony applications. The SIP specification is defined in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 3261, dated June 2002; the disclosure of which is incorporated herein by reference in its entirety. SIP is an application-layer control protocol for creating, modifying, and terminating sessions between networked endpoints, which are referred to as SIP Enabled Devices, User Agents or simply SIP endpoints.
As discussed above, SIP Enabled Devices implement a network communication protocol, wherein a communication session is established for two endpoints to transmit and receive data. As such, each SIP Device in a SIP network is assigned a unique SIP address or terminal name, which is defined in a SIP Universal Resource Identifier (URI). The format of a SIP URI is similar to that of an email address, which typically includes a user name “@” a domain name, for example “sip:alice@siemens.com.” SIP URI data is placed into header fields of SIP messages, for example to identify a sender and a receiver of the SIP message. For secure communications, the SIP Specification also defines a SIPS URI, for example “sips:alice@siemens.com.” Accordingly, when a SIPS URI is used the SIP Enabled Device associated with the SIP URI may implement an encryption protocol for transmitting data in a secure communication session. It should be noted that the SIPS URI protocol may be used interchangeably with SIP URI protocol.
The SIP communication protocol allows either a SIP server or another SIP communication end point to present a call to another SIP communication end point, such as a phone device, as a request. The SIP communication end point receiving this request may make the decision to answer based on other local settings, such as Call Forwarding, Do Not Disturb, Reject Call, or Call Deflect, at the end point. The decision could result in the call request being rejected.
In some SIP architectures it may be desirable to reduce the processing load on proxy servers that are responsible for routing requests, and improve signaling path robustness, by relying on redirection. Redirection allows servers to push routing information for a request back in a response to the client, thereby taking themselves out of the loop of further messaging for this transaction while still aiding in locating the target of the request. When the originator of the request receives the redirection, it will send a new request based on the URI(s) it has received. By propagating URIs from the core of the network to its edges, redirection allows for considerable network scalability.
Another common scenario occurs when the callee is currently not willing or able to take additional calls at the end system. A 486 (Busy Here) (SIP codes are described in detail in RFC 3261) should be returned in such a scenario. The response is passed to the INVITE server transaction, which will deal with its retransmissions. A UAS (user agent server) rejecting an offer contained in an INVITE should return a 488 (Not Acceptable Here) response. Such a response should include a Warning header field value explaining why the offer was rejected.
The disadvantage is the callee that redirects a call and provides an alternate destination, has no control on how that destination would treat the call from the caller. The result is that the caller is redirected to a destination that may not handle the call or may redirect the caller again and may not serve the intended purpose of the caller's call. Moreover, the caller may have an urgent need to only communicate with the original callee and must not be redirected. A possible scenario of this could be when the callee redirects all calls to a voice mail device when he/she sets the local phone feature of ‘Do Not Disturb’. But the callee may wish to and have the authority to over-ride the ‘Do Not Disturb’ feature in order to speak directly with the original callee.
Therefore, it is desirable to have a system that allows a caller to override any redirect/reject local feature settings.